DEC OSF/1 




DEC OSF/1 



Sharing Software on a Local Area Network 

Order Number: AA-PS3LB-TE 
February 1 994 

Product Version: DEC OSF/1 Version 2.0 or higher 



This manual describes the Remote Installation Service (RIS) utility and 
environment. RIS is a utility for installing software kits across a network 
instead of using locally mounted distribution media. 



digital equipment corporation 
Maynard, Massachusetts 



Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to 
restrictions as set forth in subparagraph (c) (1) (ii). 



Digital Equipment Corporation makes no representations that the use of its products in the 
manner described in this publication will not infringe on existing or future patent rights, nor 
do the descriptions contained in this publication imply the granting of licenses to make, use, 
or sell equipment or software in accordance with the description. 



Possession, use, or copying of the software described in this publication is authorized only 
pursuant to a valid written license from Digital or an authorized sublicensor. 



© Digital Equipment Corporation 1 994 
All rights reserved. 



The following are trademarks of Digital Equipment Corporation: 

ALL-IN- 1, Alpha AXP, AXP, Bookreader, CD A, DDIS, DEC, DEC FUSE, DECnet, 
DECstation, DECsystem, DECUS, DECwindows, DTIF, MASSBUS, Micro VAX, Q-bus, 
ULTRIX, ULTRIX Mail Connection, ULTRIX Worksystem Software, UNIBUS, VAX, 
VAXstation, VMS, XUI, and the DIGITAL logo. 



NFS is a registered trademark of Sun Microsystems, Inc. UNIX is a registered trademark 
licensed exclusively by X/Open Company Limited. 



All other trademarks and registered trademarks are the property of their respective holders. 



Contents 



About This Manual 

Audience vii 

Organization vii 

Related Documents viii 

Reader's Comments ix 

Conventions ix 

1 Introduction to Sharing Software 

1.1 The Software Sharing Environment 1-1 

1 .2 The RIS Server and Client 1-2 

1.2.1 The RIS Disk Area 1-3 

1.2.2 Multiple RIS Areas on a Server 1-4 

1.2.3 Characteristics of a RIS Client 1-5 

2 Preparing for Server Setup 

2.1 Server/Client Compatibility 2-1 

2.2 Prerequisite Server Setup Tasks 2-3 

2.2.1 Installing the DEC OSF/1 Operating System on the Server ... 2-3 

2.2.2 Setting up a Local Area Network 2-3 

2.2.3 Loading and Registering the Server Extensions License 2-4 

2.3 Distribution Media and Device Special File Names 2-5 



2.4 Planning Disk Space for RIS 2-5 

3 Setting Up a RIS Server 

3.1 Using the Remote Installation Services Utility 3-1 

3.2 Installing Software into a New RIS Area 3-1 

3.2.1 Editing the /etc/exports File 3-3 

3.3 Installing Software into an Existing RIS Area 3-4 

3.4 Using an NFS-Mounted RIS Area 3-4 

4 Managing and Maintaining RIS 

4.1 Preregistration Tasks 4-1 

4.1.1 Obtaining Information About Each Client 4-1 

4.1.2 Registering Clients' Host Names and IP Addresses with 

Servers 4-2 

4.2 Registering a Client 4-2 

4.3 Modifying Clients 4-4 

4.4 Removing Clients 4-4 

4.5 Listing Registered Clients 4-5 

4.6 Listing Products in Server Areas 4-5 

4.7 Deleting Products from RIS Server Areas 4-5 

5 Booting a RIS Client 

5.1 Remote Boot Files and Daemons 5-1 

5.1.1 The Internet Daemon and Its Configuration File 5-1 

5.1.2 The bootpd Daemon 5-2 

5.1.3 The /etc/bootptab File 5-2 

5.1.4 The tftpd Daemon 5-3 

5.2 Remote Boot Flow 5-3 



/V Contents 



6 Troubleshooting RIS 

6.1 Problems with the ris Utility Lock Files 6-1 

6.2 Problems with Client Registration 6-1 

6.3 Problems with RIS Server Response 6-2 

6.3.1 Diagnosing Response Failures on Servers Using bootp 6-3 

6.3.2 Diagnosing Response Failures on Servers Using MOP 6-4 

6.4 Problems with Loading the Correct Software 6-5 



A Installing DEC OSF/1 for Alpha AXP Subsets on an 



ULTRIX Server 
B Worksheet 
Glossary 
Index 
Examples 

5- 1: Sample /etc/bootptab File 5-2 

6- 1: Sample daemon.log File 6-4 

Figures 

1-1: RIS Server and Client 1-2 

1- 2: Generalized Illustration of the RIS Area 1-4 

2- 1: System Compatibility 2-2 



Contents v 



Tables 

5-1: Remote Boot Files and Daemons 



vi Contents 



About This Manual 



This manual describes the Remote Installation Service (RIS) utility and 
environment. RIS is a utility for installing software kits across a network 
instead of using locally mounted distribution media. 

Audience 

This manual is written for anyone using the RIS utility, typically the system 
administrator. The manual was written with the following assumptions: 

• Your hardware has been checked by you or by a Digital field service 
representative to ensure that it is working properly. 

• You have read the owner's manuals supplied with your hardware. 

• You know the location and function of the controls and indicators on 
your hardware. 

• You understand how to load and unload the installation media and any 
disks needed during the installation. 

• You know how to use the DEC OSF/1 operating system software. 

All the examples in this manual assume that you are logged in as the 
superuser on the server system. 

Organization 

This manual contains six chapters, two appendixes, a glossary, and an index. 
A brief description of the contents follows: 

Chapter 1 Introduces the concept of servers and clients. This chapter explains 
what a server is, what a client is, and how they work together. It also 
describes the basic architecture of the server/client environment. 

Chapter 2 Lists the formats in which distribution media are available and 
describes the preliminary setup procedures for RIS. 

Chapter 3 Describes the procedure for setting up a RIS server, including 
installing and updating software. 

Chapter 4 Describes processes and procedures for maintaining and managing a 
RIS system, including adding, deleting, and modifying clients and 
clients' setups. 



Chapter 5 Describes networking-related files and daemons that ris uses, and 

the process that a client goes through when it boots over the network. 

Chapter 6 Provides information on troubleshooting problems with RIS clients. 

Appendix A Explains how to install the DEC OSF/1 for Alpha AXP software 
subsets on an ULTRIX RIS server. 

Appendix B Contains a worksheet for your use in the installation process. 



Related Documents 

You should have the following documentation available: 

• The hardware documentation for your system 

• The DEC OSF/1 Release Notes 

• The DEC OSF/1 Reference Pages, Section 8 

• The Installation Guide 

• DEC OSF/1 Network Configuration 

The printed version of the DEC OSF/1 documentation set is color coded to 
help specific audiences quickly find the books that meet their needs. (You 
can order the printed documentation from Digital.) This color coding is 
reinforced with the use of an icon on the spines of books. The following list 
describes this convention: 



Audience 


Icon 


Color Code 


General Users 


G 


Teal 


System Administrators 


S 


Red 


Network Administrators 


N 


Yellow 


Programmers 


P 


Blue 


Reference Page Users 


R 


Black 



Some books in the documentation set help meet the needs of several 
audiences. For example, the information in some system books is also used 
by programmers. Keep this in mind when searching for information on 
specific topics. 

The Documentation Overview provides information on all of the books in the 
DEC OSF/1 documentation set. 
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Reader's Comments 



Digital welcomes your comments on this or any other DEC OSF/1 manual. 
You can send your comments in the following ways: 

• Internet electronic mail: 
readers_comment @ ravine . zk3 .dec.com 

• Fax: 603-881-0120 Attn: USG Documentation, ZK03-3/Y32 

• A completed Reader's Comments form (postage paid, if mailed in the 
United States). Two Reader's Comments forms are located at the back of 
each printed DEC OSF/1 manual. 

If you have suggestions for improving particular sections or find any errors, 
please indicate the title, order number, and section numbers. Digital also 
welcomes general comments. 



Conventions 

The following typographical conventions are used in this manual: 

# A number sign represents the superuser prompt. 

% cat Boldface type in interactive examples indicates typed user input. 

file Italic (slanted) type indicates variable values, placeholders, and 

function argument names. 

[ I ] In syntax definitions, brackets indicate items that are optional and 

{ I } braces indicate items that are required. Vertical bars separating 

items inside brackets or braces indicate that you choose one item 

from among those listed. 

... In syntax definitions, a horizontal ellipsis indicates that the 

preceding item can be repeated one or more times. 

cat(l) A cross-reference to a reference page includes the appropriate 

section number in parentheses. For example, cat(l) indicates 
that you can find information on the cat command in Section 1 
of the reference pages. 
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Introduction to Sharing Software 



1 



You can reduce your software and hardware costs by sharing software 
between computers. When you share software, several of the computers in 
your local area network (LAN) use a single copy of a given piece of 
software. This reduces the need for multiple copies of the same software and 
reduces the disk space required for software storage. 

You are not limited to sharing one piece of software; you can share virtually 
all of your DEC OSF/1 system software. With certain limitations, you can 
also share software for operating systems other than DEC OSF/1. 

A server is a computer system that serves another system by providing 
something that the other system wants or needs. The other system is called a 
client. A given server can serve one or many clients. Computers in a 
network can share disk space, lists of names, software kits, processing 
services, and other entities. 

1 .1 The Software Sharing Environment 

The following components make up the environment for software sharing: 

• A server 

A DEC OSF/1 server can be any Digital-supported processor running 
Version 1.2 or higher of the DEC OSF/1 operating system. See 
Appendix A for information about setting up an ULTRIX system to serve 
the DEC OSF/1 operating system. 

The server's system administrator prepares the server for Remote 
Installation Services (RIS) use by installing the DEC OSF/1 operating 
system and ensuring that the server is connected to a LAN. The system 
administrator must also ensure that there is adequate disk space in the 
/var/adm/ris directory for the subsets that the server will serve. The 
individual tasks required to set up a RIS server are described in Chapter 
3. 

• A distribution device on the server 

For DEC OSF/1 servers, the distribution device is a CD-ROM optical 
disk drive. You transfer the software subsets for one or more specific 
products and architectures from the distribution media to the RIS area on 
the server. Registered clients can then access the software. 



• An Ethernet local area network (LAN) 



You must set up the server and all client processors as hosts on the 
Ethernet. Clients use the Ethernet to access the server's RIS areas. 

• Clients 

The RIS clients are systems that can ran the operating system for which 
the server provides kits. Typically, clients are systems that ran the DEC 
OSF/1 operating system; only these processors can install the base 
operating system from a DEC OSF/1 server. Other processor families 
can install layered products after the client's operating system is running. 



1 .2 The RIS Server and Client 

Remote Installation Services (RIS) is a utility for installing software kits 
stored on a central computer system onto multiple computer systems in a 
local area network. 

With RIS, the server has a disk area set aside as the RIS area. The RIS area 
contains copies of software kits to be made available for installation onto 
clients. Figure 1-1 illustrates how the RIS system works. 



Figure 1-1: RIS Server and Client 




ZK-0268U-R 



In the RIS area, the server also maintains information about each client 
system so that the client's administrator can install software kits without 
information from the server's administrator. Kits are organized so that a 
given product can use multiple kits which reflect the differences between 
multiple hardware platforms. The server's RIS area is made available for 
read-only access to clients by means of a network file sharing system. 
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The server is a passive partner in the day-to-day operation of a RIS system. 
Beyond verifying clients' identities and their kit load requests, and managing 
accepted requests, the server does not interact directly with the clients. A 
system does not have to be a dedicated RIS server; it can also support local 
timesharing users. 

A RIS client installs software kits by using the setld utility; the utility 
copies the kit contents across the network from the server instead of from 
local media. 

The following are some of the features and benefits of RIS: 

• Installation and set up of servers and clients are done by scripts, thereby 
simplifying the server system administrator's task. Maintenance of the 
server's disk areas is similarly straightforward. The system interface is 
the same regardless of system type. 

• Because the RIS software supports both different hardware platforms and 
different software versions, it is adaptable to a wide variety of customer 
systems and requirements. Servers running a given version of the DEC 
OSF/1 system can serve clients running the same version or an earlier 
version of the system. 

• RIS uses a single set of kit files for all clients having the same 
architecture. Disk space requirements on the server are greatly reduced. 

1.2.1 The RIS Disk Area 

In addition to the server's normal disk area, a partition or area is reserved on 
the server to hold RIS software kits. This RIS area contains one or more 
product environments. Each product environment contains one or more 
software kits suitable for installation on a given hardware/software platform. 
See Figure 1 -2 for a generalized illustration of the RIS area. 
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Figure 1-2: Generalized Illustration of the RIS Area 
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In Figure 1-2, the RIS area, /var/adm/ris, contains one product 
environment, risO . alpha. A given environment is designated to contain 
products for a specific target platform; in Figure 1 -2, the target platform is 
Alpha AXP processors. Multiple product environments can exist in a single 
RIS area. Each environment contains one or more product directories, each 
of which in turn contains several product kit archives, called subsets. For 
example, an area named risO . alpha could contain directories called 
product_001, product_002, product_003, and so on. Figure 1-2 
shows two product directories. 

Figure 1-2 also shows the kit /is 1 area, which is created when you register 
the first RIS client on the server. The kit/ is 1 directory contains 
installation tools required by clients when they install software over the 
network. 

The server itself does not normally use any of the RIS area. System 
administrators can access the product area as required for maintenance and 
for installation or removal of product kits, but the area is not considered part 
of the server's own disk area. 

1.2.2 Multiple RIS Areas on a Server 

For more flexibility, you can establish multiple RIS areas in separate 
partitions. RIS areas on a given server can be exported to other servers using 
the Network File System (NFS). Servers that import such RIS areas can use 
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them as if they were local, supplying the imported subsets to their own sets 
of clients. Network Configuration describes how to export and import file 
systems. 

.3 Characteristics of a RIS Client 

A RIS installation uses the local area network as its installation media. A 
RIS client can install any software kit for which it is registered on the server. 
The installation procedure runs entirely on the client and, after the necessary 
software is installed, no continuing relationship is required between the RIS 
server and client. 

The DEC OSF/1 operating system itself can be among the kits that are 
available from the server. To install the operating system, the client 
processor is booted across the network using a generic minimal kernel and 
file system, both of which are part of the software kit. The special kernel and 
file system become resident in the client's memory. Once booted, the client 
runs the same installation utility, called set Id, that is used to install kits on 
an already-running, configured platform. For more information about the 
setld utility, see the setld(8) reference page. After the installation is 
complete, the system is rebooted using the newly installed software. 

Note 

A client should be registered with one server only for the base 
operating system. If you register a client with more than one 
server for the base operating system, each server with which the 
client is registered trys to respond to the client's network boot 
request. 

To change the server with which a client is registered for the 
base operating system, first remove the client from the current 
server's client database and then register it with the new server. 
See Chapter 4 for information about registering and removing 
RIS clients. 

A client can be registered with multiple servers for optional 
subsets and products other than the base operating system. 
When you load optional subsets or layered products with the 
setld command, you specify the name of the server from 
whom to copy the kits. 
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Preparing for Server Setup 



This chapter provides the information you need before you begin setting up a 
DEC OSF/1 RIS server. The topics discussed include: 

• Server/client compatibility 

• Tasks you must complete before installing RIS 

• Names of distribution media and device special files 

• Disk space requirements for RIS 



2.1 Server/Client Compatibility 

Support for differing bootstrap protocols constrains the use of the DEC 
OSF/1 and ULTRIX operating systems together in RIS environments. 
Whereas DEC OSF/1 RIS servers respond to client bootp requests, 
ULTRIX RIS servers respond to client MOP requests. 

DEC OSF/1 clients can broadcast either bootp or MOP requests. 
Practically, this means that DEC OSF/1 clients can boot from either an 
ULTRIX RIS server or a DEC OSF/1 RIS server. ULTRIX clients only 
broadcast MOP requests, which means they can only boot from ULTRIX RIS 
servers. 

Once a client's operating system is installed and running, a server running 
either ULTRIX or DEC OSF/1 can serve additional product subsets to a 
client running the other operating system. The client loads the additional 
subsets using the set Id utility. 

Figure 2-1 illustrates these relationships: 



Figure 2-1: System Compatibility 
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An ULTRIX RIS client can be booted by an ULTRIX RIS server using 
the MOP protocol. This means that an ULTRIX server can serve both 
the ULTRIX base operating system as well as additional product subsets 
to an ULTRIX client over the network. The ULTRIX client loads 
additional product subsets using the setld utility. 

A DEC OSF/1 RIS client can be booted by an ULTRIX RIS server using 
the MOP protocol. This means that an ULTRIX server can serve both 
the DEC OSF/1 base operating system as well as additional product 
subsets to the DEC OSF/1 client over the network. The DEC OSF/1 
client loads additional product subsets using the setld utility. 

A DEC OSF/1 RIS client can be booted by a DEC OSF/1 RIS server 
using the bootp protocol. This means that a DEC OSF/1 server can 
serve both the DEC OSF/1 base operating system as well as additional 
product subsets to the DEC OSF/1 client over the network. The DEC 
OSF/1 client loads additional product subsets using the setld utility. 

ULTRIX RIS clients cannot be booted by DEC OSF/1 RIS servers. This 
means that a DEC OSF/1 server cannot serve the ULTRIX base operating 
system over the network. However, after the ULTRIX operating system 
is up and running on the client, the DEC OSF/1 server can serve an 
ULTRIX client additional product subsets. The ULTRIX client loads 
additional product subsets using the setld utility. 
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2.2 Prerequisite Server Setup Tasks 

Before you begin to configure and install the RIS areas and software on the 
server, you must perform the following tasks: 

1. Install the DEC OSF/1 operating system. 

2. Set up your Ethernet local area network (LAN). 

3. Load and register the DEC OSF/1 Server Extensions (OSF-SRV) license. 

2.2.1 Installing the DEC OSF/1 Operating System on the Server 

The Installation Guide describes how to install the DEC OSF/1 operating 
system on the server. It also lists all of the standard DEC OSF/1 supported 
software subsets with subset names and descriptions of subset contents. 
Subset sizes are listed in the Release Notes. You need this information to 
install the operating system, as well as to install RIS software. 

To be a RIS server a system must have the Remote Installation 
Service and Additional Networking Services subsets, which 
contain the tf tp networking utility and the bootpd bootstrap daemon, 
installed. 

To see whether these subsets are installed, enter the following command: 
# /usr/sbin/setld -i | egrep "RIS|lNET" 

Information similar to the following should be displayed: 

OSFCLINET200 installed Basic Networking Services 

OSFINET2 00 installed Additional Networking Services 

OSFRIS200 installed Remote Installation Service 

The Basic Networking Services subset is mandatory and is installed 
automatically. If the Additional Networking Services and 
Remote Installation Service subsets are not installed, you must 
install them using the setld utility. 

See the Installation Guide for more information about using setld to install 
subsets. 

2.2.2 Setting up a Local Area Network 

You must connect the RIS server and all of the client processors to Ethernet 
local area networks. Note that the server and clients must all be on the same 
network or subnetwork unless the router connecting the networks or 
subnetworks can forward bootp requests. 

For instructions on setting up a local area network, refer to Network 
Configuration. 
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2.2.3 Loading and Registering the Server Extensions License 

The DEC OSF/1 Server Extensions license (OSF-SRV) provides the right to 
use the RIS software on DEC OSF/1 systems. A product authorization key 
(PAK) accompanies the license. You must register the PAK information for 
your system before it can be configured as a RIS server. Register the PAK 
information by using the lmf (8) utility. 

To load and register your license, complete the following steps: 

1. Log in as root and run the lmf register utility as follows: 

# lmf register 

Licensed Software Product 
Product Authorization Key 

Enter data on lines terminated with : 

Issuer: 

Authorization Number: 

Product Name: 
Producer: 

Number of units: 

Version : 
Product Release Date: 

Key Termination Date: 

Availability Table Code: 
Activity Table Code: 

Key Options: 
Product Token: 
Hardware-Id: 
Checksum: 

Comment : 

Complete the template using the information provided in the OSF-SVR 
PAK. 

2. Run the lmf reset utility as follows: 

# lmf reset 

The lmf reset command adds the OSF-SRV license to the kernel 
license cache, which is where the system checks to determine whether 
your system is authorized to act as a server. 

3. Check whether the PAK is registered correctly by running the lmf 
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list utility as follows: 

# lmf list | grep OSF-SVR 

OSF-SVR active unlimited 

The lmf list utility displays the products registered with LMF, their 
status, and the number of users authorized to use each product. 

See Software License Management and the lmf (8) reference page for 
more information about registering license PAKs. 

After you enter the data, complete the server setup tasks described in Chapter 
3. 



Distribution Media and Device Special File Names 

The DEC OSF/1 distribution kit contains a CD-ROM for RRD40 or RDD42 
CD-ROM readers. The device special file name for a CD-ROM reader is 
/dev/ rznc, where the character n represents the unit number. 

Planning Disk Space for RIS 

As with any installation, you must calculate the amount of disk storage 
required for the software subsets in the RIS areas on the server before 
beginning. If space on the server's system disk is an issue and your server's 
distribution medium is a CD-ROM, you might want to create symbolic links 
from the RIS server area to the software on the CD-ROM. Section 3.2 
briefly describes the advantages and disadvantages of establishing symbolic 
links instead of extracting the software subsets into the RIS server area. 

See Chapter 1 for a description of the RIS area's contents. Note that a given 
server can have multiple RIS areas, in which some of the subsets can be 
duplicated. To organize your RIS server's disk space, perform the following 
steps: 

1 . Determine how many RIS environments you want. 

2. Choose the software subsets you want to install, organizing them by the 
environments into which they are to be installed. 

3. Use the subset size information in the Release Notes to ensure that you 
have adequate disk space. 
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Setting Up a RIS Server 



This chapter describes how to use the ris utility to configure a DEC OSF/1 
RIS server. Topics discussed include: 

• Establishing a new RIS server environment using ris 

• Installing software kits in existing RIS environments 

Chapter 4 provides information about using the ris utility to perform the 
day-to-day tasks associated with managing a RIS server. 

3.1 Using the Remote Installation Services Utility 

The RIS utility offers two usage styles: You can use it interactively through 
a menu-driven interface, or you can issue commands to perform the various 
tasks one at a time. This chapter describes how to use the utility's menu 
interface; Chapter 4 describes how to use individual ris commands. 

3.2 Installing Software into a New RIS Area 

After you create a RIS environment and install the first software kits there, 
you can install more kits into that environment or create other environments 
as you need them. (Section 3.3 describes how to install additional software 
into an existing RIS environment.) 

Note 

If your network includes ULTRIX systems, you can use those 
systems as RIS servers to provide the DEC OSF/1 software. See 
Appendix A for additional information about installing the DEC 
OSF/1 software on an ULTRIX server. 

Use the following procedure to create a new risn . alpha environment and 
install the first software kit into it: 

1 . If your distribution media is CD-ROM, enter a mount command similar 



to the following before starting the utility: 

# mount -dr /dev/rz4c /mnt 

This example uses a CD-ROM drive that is unit 4; if your drive is a 
different unit, substitute the device special file name for that unit. 

If you are uncertain of your CD-ROM's unit number enter the file 
command, specifying the raw device, as follows: 

# file /dev/rrz*c 

/dev/rrzlc: character special (8/1026) SCSI #0 RZ25 disk #8 (SCSI ID #1) 

/dev/rrz2c: character special (8/2050) SCSI #0 RZ25 disk #16 (SCSI ID #2) 

/dev/rrz3c: character special (8/3074) SCSI #0 RZ25 disk #24 (SCSI ID #3) 

/dev/rrz4c: character special (8/4098) SCSI #0 RRD42 disk #32 (SCSI ID #4) 

/dev/rrz9c: character special (8/17410) SCSI #1 RZ57 disk #72 (SCSI ID #1) 

Your CD-ROM device corresponds to an RRD device, in this case 
RRD42. 

2. Invoke the ris utility by entering the following command at the system 
prompt: 

# /usr/sbin/ris 

The Remote Installation Services menu is displayed. 

Each menu item is preceded by a letter. The first time you invoke the 
utility, the display looks similar to the following: 



*** RIS Utility Main Menu *** 



Choices without key letters are not available. 



) ADD a client 

) DELETE software products 

i) INSTALL software products 

) LIST registered clients 

) MODIFY a client 

) REMOVE a client 

) SHOW software products in remote installation environments 

x) EXIT 



Enter your choice: 

The utility's menu does not display option letters for menu items that 
cannot currently be performed. 

As you add environments, software, and clients to the system, options 
that were not available become available, and the menu displays their 
option letters. 

3. Choose the "Install software products" item. 

A menu offers the installation options available. 
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4. Choose item 1 to establish a new RIS area. 

5. Enter the full pathname of the device special file name or mount point for 
the distribution media. 

If your distribution media is CD-ROM, the device special name for RIS 
is /mnt /ALPHA/BASE. 

The utility allows you to choose whether you want to create symbolic 
links to the software or to extract the software into the RIS area. 

If you choose to extract subsets, the subsets you select are copied from 
the CD-ROM into the RIS area. You must know which specific subsets to 
extract and the amount of disk space required. See Section 2.4 for 
information about planning disk space for RIS. Clients can only install 
the subsets that were extracted into RIS product areas for which they are 
registered. 

If you choose to link to the CD-ROM, symbolic links are created in the 
RIS area that points to the subset directories on the CD-ROM. No disk 
space planning is required because the subsets reside on the CD-ROM. 
However, the CD-ROM must be online and mounted for clients to access 
the subsets. Unlike subset extraction, no subset selection is required. 
Clients registered for RIS product areas that are links to the CD-ROM 
can access all subsets. 

6. If you chose to extract subsets, the utility lists the mandatory and optional 
software subsets that you can install. Choose the subsets that you want 
from the list. The utility displays your list for confirmation. 

When you confirm your selections, the ris utility extracts the subsets 
and displays the name of the new RIS environment. The main menu is 
then displayed. 

Once you set up the RIS areas and registered clients, the clients can access 
the areas they need. Client registration is discussed in Chapter 4. 

3.2.1 Editing the /etc/exports File 

Client RIS installations rely on files located in the server's 
/var/adm/ ris/risn . arch/kit directory, and therefore require that 
the server export that directory. In this directory path, n is the number of the 
RIS area and arch is the architecture of the client systems that the area will 
serve. When you create the RIS area, risn .arch , the ris utility supplies 
you with a name based on the choices you make during the area's creation. 

The server's / etc /exports file must include an entry for each RIS area 
that it is exporting. When you create a RIS area, the ris utility 
automatically edits the / etc /exports file and adds the correct entry for 
that area. 
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The RIS area entries in the /etc /exports file of a system that acts as a 
RIS server for two alpha environments and one RISC environment look 
similar to the following: 

/var/adm/ris/risO . alpha/kit -root=0 -ro 
/var/adm/ris/risl . alpha/kit -root=0 -ro 
/var/adm/ris/risO .mips/kit -root=0 -ro 

Note 

When you register the first client on your RIS server, the r is 
utility creates the kit/ is 1 directory, which contains tools that 
clients require to install software subsets. 



3.3 Installing Software into an Existing RIS Area 

You can install software subsets that are compatible with the DEC OSF/1 
setld utility into an existing RIS environment by using the ris command. 
From the installation menu, choose the option to add software to an existing 
area. 

The utility displays a list of the existing areas. 

1 . Choose the area that you want to use, and then proceed as before to 
mount the distribution media and choose subsets. 

2. Repeat this procedure for each additional group of subsets you want to 
install. 



3.4 Using an NFS-Mounted RIS Area 

You can use an NFS mount point to install software from a RIS area that you 
import from another machine. For example, if a system named salaam has 
a CD-ROM containing the DEC OSF/1 subsets mounted on /mnt and listed 
in its /etc /exports file, the system administrator on aladdin can NFS 
mount that CD-ROM with the following command: 

aladdin_root# mount salaam: /mnt /ALPHA/ BASE /mnt 

Once the CD-ROM is mounted, aladdin' s system administrator can use 
the ris utility to install software from it as if it were local to aladdin. 
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Managing and Maintaining RIS 



This chapter describes how to use the r is utility to manage DEC OSF/1 RIS 
environments and clients. Topics discussed include: 

• Preregistration tasks 

• Registering a client 

• Modifying a client 

• Removing a client 

• Listing registered clients 

• Listing products in the server's RIS areas 

• Deleting software products from the server's RIS areas 

4.1 Preregistration Tasks 

Before you register RIS clients, gather the information required for each one. 
The RIS Client Configuration Worksheet in Appendix B will help you 
organize your information for ready access as you register clients. Fill out a 
worksheet for each client you want to register. 

Perform the following tasks to prepare to register clients: 

• Obtain information about each client and fill out a copy of the RIS Client 
Configuration Worksheet from Appendix B. 

• Register each client's host name and Internet Protocol (IP) address with 
the appropriate naming service server or servers. 

4.1.1 Obtaining Information About Each Client 

You need the following information about each processor you plan to register 
as a client: 

• Host name (see Section 4.2 for restrictions on host names) 

• The RIS environments you want to make available to the client 

• The hardware platform type of the client 



• Hardware Ethernet address of the client 

4.1 .2 Registering Clients' Host Names and IP Addresses with 
Servers 

If the host system is served by any of the following naming services, check 
with your site administrator to be sure that your clients are registered with 
the appropriate naming service servers: 

• /etc/hosts 

• Berkeley Internet Name Domain (BIND) 

• Network Information Service (NIS), formerly called Yellow Pages (YP) 

See Network Configuration for information about configuring naming 
services on a local area network and registering clients with them. 

4.2 Registering a Client 

To register a client processor using the menu, follow this procedure: 

1. Invoke the ris utility by entering the following command: 
# /usr/sbin/ris 

2. Choose the option to add a client processor from the Remote Installation 
Services menu. 

A message indicating that you have chosen to add a client processor 
displays, and a prompt asks if you want to continue with the procedure 
for adding a client processor. After you confirm that you want to 
continue, a prompt asks for the client's host name. 

Caution 

Only lowercase letters (a-z) and numbers are permitted in 
host names, and a host name must begin with a letter, not a 
number. Invalid host names can corrupt the RIS database. 

3. Enter the client's host name. 

The client processor must be registered with the appropriate naming 
service or you can not register the client with RIS. If the client is not 
registered with the appropriate naming service, the utility displays an 
error message and repeats the prompt. 

4. Select an environment for the client. 

The utility lists the available environments for which you can register the 
new client. Choose the appropriate environment. 
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5. Select the products within the environment that you want to be available 
to the client. 

The utility lists the products available in the chosen environment. Enter 
the numbers of the products you want this client to be able to install. 
When the utility asks you to confirm your choices, you can accept them 
or respecify the information. 

6. Enter the client's hardware Ethernet address. For example: 

Enter the client processor's hardware Ethernet 
or FDDI address, for example, 
08-00-2f-03-f 5-08 : 08-00-2B-07-aa-eb 

If you do not know it, you can obtain the client's hardware address in one 
of the following ways: 

- On a client that is not currently up and running (you are at the boot 
prompt), issue the appropriate console command or commands for 
that type of client. Console commands are processor specific, so you 
must refer to your hardware documentation for the correct commands. 
With the correct console commands you can display the current 
environment variables or show the client's devices. The hardware 
address associated with the network interface or interfaces is 
displayed. 

- On a running DEC OSF/1 client, issue the uerf — r 300 command 
as superuser. Search the output for the string hardware address. 
Either the line containing this string or the one following it contains 
the hardware address. For example: 

# uerf -r 300 | grep -i "hardware address" | uniq 

_hardware address: 08-00-2f-ef-lf-10 

If the hardware address is on the line following the one that contains 
the string hardware address, you must manually search the 
output from the uerf command to find the correct hardware address. 

- From the RIS server, you can determine the hardware address of a 
running DEC OSF/1 client using the ping and arp commands. To 
determine the hardware address of the RIS client spike do the 
following: 

# /usr/sbin/ping -q -cl spike; arp spike 

PING spike.cities.dec.com (152.90.224.30): 56 data bytes 

spike.cities.dec.com PING Statistics 

1 packets transmitted, 1 packets received, 0% packet loss 
round-trip (ms) min/avg/max = 0/0/0 ms 
spike (152.90.224.30) at 08-00-2B-03-09-BF 

The hardware address in this case is 08-00-2B-03-09-BF. 
If you do not enter the address in the correct format, the utility displays 
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an error message and repeats the prompt. 

Note 

Except for checking the format of the number you enter, the 
ris utility does not verify its validity. 

You can add a single RIS client by invoking the ris utility with its —a 
option. Further options supply the Ethernet address, path, and product list. 
The syntax of the command is: 

/usr/sbin/ris -a clientname -h Ethernet-address -p path, product [ .product... ] 
For example: 

# /usr/sbin/ris -a minaret -h 08-00-2B-03-05-8B -p \ 
risO . alpha , product_00 1 

4.3 Modifying Clients 

You can modify a RIS client's Ethernet address, its RIS environment 
information, and the list of products it can install. To modify a client's 
entry, follow these steps: 

1. Invoke the ris utility and choose the option to modify a client. 

2. Choose the client you want to modify from the list displayed. 

The remainder of the modification procedure is much like the procedure for 
adding a client, as described in Section 4.1. 

4.4 Removing Clients 

You can remove clients by using the ris utility's menu interface or by 
issuing commands from the command line. To remove a client by using the 
menu, follow these steps: 

1. Invoke the ris utility and choose the option to remove a client 
processor. 

2. Enter the name of the client processor to remove when prompted by the 
utility. 

3. Verify that you want to remove the client processor. 

After you confirm your choice, the utility deletes the client's registration. 

When removal is complete, the utility returns you to its main menu. 

You can also use a ris command line to remove several clients at once. For 
example: 
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# /usr/sbin/ris -r houri scimitar 



Listing Registered Clients 

You can view a list of the registered clients by invoking the ris utility and 
choosing the "List Registered Clients" option. If there are no registered 
clients, the utility indicates this fact; if there are registered clients, the utility 
displays the list. 

Listing Products in Server Areas 

You can view a list of the current products in a given server area by invoking 
the ris utility and choosing the option to show products. 

You can also use a ris command line to show the products installed in each 
server area. For example: 

# /usr/sbin/ris -s 

Show Products in RIS Server Areas: 

1 /var/adm/ris/risO .alpha 

DEC OSF/1 Worksystem Software V2 . 0 



Deleting Products from RIS Server Areas 

You can delete one or more of the current products in a given RIS area by 
invoking the ris utility and choosing the option to delete products. The 
utility asks you to choose a RIS area and then guides you through the 
procedure to delete products. 
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Booting a RIS Client 



If you use RIS to install the DEC OSF/1 operating system on a client, the 
client must boot across the network. This chapter describes the network files 
and daemons that the r is utility uses, and the sequence of events from when 
a client broadcasts a bootp request to when it boots. 

Note 

The client must be registered on the RIS server before you can 
install the operating system. 



5.1 Remote Boot Files and Daemons 

Table 5-1 describes the files and daemons used by RIS servers to boot a 
remote client. 

Table 5-1 : Remote Boot Files and Daemons 



Name 

/ etc/bootptab 
/etc/inetd. conf 
/usr/sbin/bootpd 
/usr/sbin/tf tpd 
/usr/sbin/inetd 



Description 

Contains information needed to boot remote clients 
Contains start-up information for various internet daemons 
bootp server daemon (handles bootp requests) 
tf tpd server daemon 
Internet server daemon 



5.1.1 The Internet Daemon and Its Configuration File 

The inetd daemon starts networking-related daemons on a DEC OSF/1 
system. Some of these daemons, such as bootpd are related to remote 
installation; others, such as f ingerd, are not used by RIS. On request, the 
inetd daemon starts any of the daemons listed in its configuration file, 
/etc/inetd. conf. 

When the inetd daemon starts, it reads the /etc/inetd. conf file. It 
rereads the /etc/inetd. conf file when it receives the hangup signal 



HUP or -1. 

When a RIS server is configured, the r is utility adds a bootpd entry to the 
end of the server's /etc/inetd.conf file. This enables the server to use 
bootp to boot a remote client. See the inetd(8) and the inetd . conf (8) 
reference pages for more information. 

5.1.2 The bootpd Daemon 

The bootpd daemon handles remote boot requests. It starts when the RIS 
server system senses a bootp request on the network. As it starts up, the 
bootpd daemon reads its /etc/bootptab file to determine the systems 
from which it will recognize remote boot requests. Whenever the 
/etc/bootptab file is modified, bootpd rereads it. 

Section 5.1.3 describes the content and format of the /etc/bootptab file. 
See the bootpd(8) reference page for more information. 

5.1 .3 The /etc/bootptab File 

The /etc/bootptab file is a text file that contains information that a 
server needs to boot a remote client. The ris utility adds and removes 
entries from this file during client management. Other applications may also 
place entries in the /etc/bootptab file. 

The general format for entries in the bootptab is as follows: 

tag: tg= value...: tg= value...: tg= value... 

Example 5-1 shows sample /etc/bootptab file entries for a RIS client. 

For additional information about the contents of the bootptab file, see the 
bootpd(8) reference page. 

Example 5-1: Sample /etc/bootptab File 

ris . dec : hn : ht=ethernet : vm=rf cl 04 8 U 

risO . alpha : tc=ris . dec : bf =/var/adm/ris /risO . alpha /vmunix : [2] 

spike :tc=ris0. alpha : ha=08002b08002b: ip=16 . 30. 0. 143: S 

U The ris . dec entry defines characteristics common to all clients. The 
fields specify the following: 

- hn: Tells the boot server to send the name of the client system to the 
client when it makes a boot request. 

- ht: Client' s hardware type 

- vm: Vendor-specific information 

[2] The risn .arch entry, in this example risO . alpha, defines 
characteristics common to all clients using this RIS area. The fields 
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specify the following: 

- tc: Table continuation 

The tc field allows you to follow pointers back to common entries. 
For example, the tc entry for risO . alpha in Example 5-1 points 
to the ris . dec entry. The ris . dec entry contains the common 
hardware type (ht) and vendor specific (vm) information. The 
risO .alpha entry, itself, contains common information about the 
boot file location. 

- bf : Name of the boot file 

[3| The hostname entry, in this example spike, defines characteristics 
for a specific client. The fields specify the following: 

- tc: Table continuation 

You should understand the host spike's entry as follows: its tc 
entry points to risO . alpha, which contains its boot file 
information. risO . alpha, in turn, points back to ris . dec which 
contains relevant hardware type and vendor specific information. 

If you added another host entry to the /etc/bootptab file, it 
would look similar to the following: 

lee:tc=risO . alpha : ha=0 80 02babf ace : ip=16 . 140. 64. 249: 

- ha: Client's Ethernet hardware address 

- ip: Client's IP address 



4 The tftpd Daemon 

The tftpd daemon handles the transfer of the boot file during a remote 
boot. This daemon starts when there is a file to be transferred. See the 
tf tpd(8) reference page for more information. 



Remote Boot Flow 

DEC OSF/1 client systems use the bootp protocol to perform the remote 
bootstrap operation. The command used to initiate a remote boot is processor 
specific. However, once the remote boot operation has started, the underlying 
process is the same for all DEC OSF/1 systems: 

1 . The processor-specific remote boot command is issued at the client 
console prompt. 

2. The client processor firmware sends a bootp packet over the Ethernet. 
This packet contains the hardware Ethernet address of the client. 

3. The bootp server daemon ( bootpd) compares the Ethernet hardware 
address in the packet with the client registration information stored in its 
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/etc/bootptab file to determine if the client requesting the remote 
boot is registered to the server. 

4. If the address matches one in its /etc/bootptab file, the bootpd 
daemon sends to the client a packet of information that includes the 
server's Internet address, client's Internet address, and the name of the 
file to be loaded from the server. This information was placed in the 
bootptab file when the client was registered on the server. 

The Internet addresses are used to set up a network that is used to 
download to the client processor the file specified in the bootptab file. 
For DEC OSF/1 RIS clients, this file is 

/var/adm/risn . alpha/vmunix, where risn. alpha corresponds 
to the RIS area to which the client is registered. This file is the DEC 
OSF/1 standalone system used to start the installation. 

5. The client system requests the file from the server system. 

6. The client and server system use the tf tp protocol to transfer vmunix 
to the client. 

7. Once vmunix is loaded, the client system begins to execute vmunix 
and the DEC OSF/1 standalone system messages display on the client 
console terminal. 

After the operating system is installed, the client is a self-supporting system. 
Follow normal procedures to boot the system from its own local disk. 
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Troubleshooting RIS 



This chapter contains information to assist you in troubleshooting problems 
with your RIS system. Topics discussed include: 

• Problems with the ris utility 

• Problems with client registration 

• Problems with RIS server response during booting 

• Problems in loading the correct kernel file once booting has commenced 

6.1 Problems with the ris Utility Lock Files 

To prevent multiple users from performing operations on RIS areas 
simultaneously, when a user selects a ris menu item, the ris utility creates 
two lock files in the /tmp directory, rislock and ris . tty . lock. If 
the ris utility is run by another user, or the same user on a different 
terminal, all menu selections generate a message similar to the following: 

The ris utility is currently locked while j_smith on /dev/ttyp3 
is installing software. Try again later. 

If the ris utility is stopped prematurely, these lock files may not be 
removed. If the lock files are not removed, the message displays even 
though no other user is using RIS. 

If this occurs, you must delete the lock files from the /tmp directory. 

Caution 

Before deleting the lock files, ensure that no other user is using 
the ris utility. 

6.2 Problems with Client Registration 

The server requires a client's Ethernet hardware address in order to boot the 
client over the network. The ris utility prompts you for the client's address 
during the registration process. If it does not, check the following: 

• If the RIS area is linked to a CD-ROM 

Check that the CD-ROM that is the target of the links is mounted. 



• If the RIS area is serving a pre-2.0 version of DEC OSF/1 

Check that the mandatory update subsets for the release the server is 
serving are installed in the server's RIS area. Install the mandatory update 
subsets from the / local_mnt /ALPHA/UPDATE directory on the DEC 
OSF/1 distribution CD-ROM. For example, if the CD-ROM is installed 
on / mnt, install the mandatory update subsets from the 
/mnt /ALPHA/UPDATE directory. 

• If the RIS area is serving version 2.0 of DEC OSF/1 

Check that the mandatory operating system subsets are installed into the 
RIS area. Install the mandatory subsets from the 

/ local _mnt /ALPHA/BASE directory on the DEC OSF/1 distribution 
CD-ROM. For example, if the CD-ROM is installed on /mnt, install the 
mandatory update subsets from the /mnt /ALPHA/BASE directory. 

Note 

If you do not intend to boot the client over the network, the 
server does not require the client's Ethernet hardware address. 
The client can use the set Id utility to load optional subsets or 
layered product subsets over the network. See System 
Administration for more information about loading subsets with 
the set Id utility. 



6.3 Problems with RIS Server Response 

Typically, booting failures occur because the information possessed by the 
server is invalid. The following two server files are involved in handling RIS 
clients. You should check them in the order listed: 

• /var/adm/ris/clients/risdb 

This file is created and managed by the ris utility; it contains the 
utility's view of the environment. Run the ris utility to show the 
configuration for the client in question. Verify that the client is registered 
and that its registration information is correct. If not, use the ris utility 
to add or modify the client's registration. 

• /etc/bootptab (DEC OSF/1 servers only) 

This file is not exclusively used by RIS which means that it can be edited 
for other purposes, and the entry for your client could have been 
corrupted. Examine the client's bootptab entry to ensure that the entry 
agrees with both the risdb entry and the addresses and parameters of 
the equipment in your environment. The contents of the 
/etc/bootptab file are described in the bootpd(8) reference page. 
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.1 Diagnosing Response Failures on Servers Using bootp 

DEC OSF/l servers respond to bootp requests from DEC OSF/l clients. If 
the DEC OSF/l server's information is correct for the client but the server 
still fails to respond, enable logging of bootp messages on the server by 
editing the server's /etc/inetd . conf file and modifying the line for 
bootps to include the — d option as a bootpd command argument. For 
example: 

bootps dgram udp wait root /usr/sbin/bootpd bootpd -d 

Then, find the process IDs for the Internet daemons. Send a HUP signal to 
the inetd daemon so it will reread the /etc/inetd. conf configuration 
file, and kill the bootpd daemon. For example: 

# ps x | egrep " inetd | bootpd" 

228 ?? I 0:00.93 /usr/sbin/inetd 

243 ?? I 0:00.91 /usr/sbin/bootpd 

9134 p2 S 0:00.23 egrep inetd | bootpd 

# kill -HUP 228 

# kill -KILL 243 

Caution 

You must kill the inetd daemon before killing the bootpd 
daemon. 

It is not necessary to restart the bootpd daemon manually; the inetd 
daemon starts it automatically. 

To track boot requests as they occur, run the tail — f command on the 
/var/adm/syslog.dated/today ' s-da te/daemon. log file and 
then try to boot the client. Many daemons other than the bootpd daemon 
log information to the daemon . log file; however, the log file clearly shows 
the client's boot requests, indicating a hardware address that matches the 
address in the /etc/bootptab file. 

If the client's boot requests are not logged, you can enable more thorough 
logging by editing the / etc/inetd . conf file again, adding a second — d 
option to the bootpd command. Each additional instance of the — d option 
(up to three) enables increased reporting; the second instance enables the 
server to report all boot requests, even those for client systems it does not 
recognize. This level of reporting should help you determine where in the 
system the request is being lost. 

If you modify the /etc/inetd. conf file remember to restart the inetd 
daemon by sending it a HUP signal. Example 6-1 shows a sample section of 
a daemon . log file. It illustrates the kind of information logged by various 
system daemons, and, more specifically, by the bootpd daemon when it is 
run with two — d flags set. 
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Example 6-1: Sample daemon.log File 



Jul 28 14:56:36 ludwig mountd [ 1 9 1 ] : startup 

Jul 28 14:56:38 ludwig xntpd[235]: xntpd version 1.3 U 
Jul 28 14:56:43 ludwig mold[269]: mold (VI. 10) initialization complete 
Jul 28 14:56:44 ludwig evd[272]: E003 - evd (VI. 10) initialization complete 
Jul 28 14:56:45 ludwig internet_mom[ 275 ] : internet_mom - Initialization 
complete . . . 

Jul 28 14:56:45 ludwig snmp_pe[ 278 ] : M004 - snmp_pe (VI. 10) initialization 
complete 

Jul 28 16:34:55 ludwig inetd[282]: /usr/sbin/bootpd: exit status 0x9 12 
Jul 28 16:35:47 ludwig bootpdf 1228 ] : bootpd 2.1a #0: \ i 

Fri Feb 05 00:32:28 EST 1993 
Jul 28 16:35:47 ludwig bootpd[ 1228 ] : reading " /etc/bootptab" 
Jul 28 16:35:47 ludwig bootpdf 1228 ] : read 3 entries from "/etc/bootptab" 
Jul 28 16:35:47 ludwig bootpdf 1228 ] : request from hardware address \ 5] 

08002B2C9C6F 

Jul 28 16:35:47 ludwig bootpdf 1228 ] : hardware address not found: 08002B2C9C6F 
Jul 28 16:36:08 ludwig bootpdf 1228 ] : request from hardware address \ |§| 
08002B2FFACE 

Jul 28 16:36:08 ludwig bootpdf 1228 ] : found: hostl.dec.com ( 08002B2FFACE ) at 
(16.69.224.83) 

Jul 28 16:36:08 ludwig bootpdf 1228 ] : file /var/adm/ris/ris0.alpha/\ 

vmunix. hostl . dec . com 
Jul 28 16:36:08 ludwig bootpdf 1228 ] : vendor magic field is 0.0.0.0 
Jul 28 16:36:08 ludwig bootpdf 1228 ] : sending RFC1048-style reply 

U Many daemons log information to this file. 

[H Result of sending a HUP signal to the inetd daemon and killing the 
bootpd daemon. 

|3| A new bootpd daemon starts up in response to a boot request. The 
bootpd daemon reads the /etc/bootptab file as a part of its startup. 

ID A bootp request by a system with hardware address 08002B2C9C6F. 
Because the system is not a client of this RIS server, its hardware address 
is not in the server's /etc/bootptab file. 

[5] A bootp request by system with hardware address 08002B2FFACE. 
The system is a client of this RIS server. 



6.3.2 Diagnosing Response Failures on Servers Using MOP 

If an ULTRIX server's information is correct for a DEC OSF/1 client but the 
server still fails to respond, enable display of verbose MOP protocol 
messages on the client by adding an argument consisting of the letter V (in 
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quotation marks) to the boot command. For example, on a DEC 3000, enter 
the following boot command at the console prompt: 

»> boot -fl "V" esaO 

Problems with Loading the Correct Software 

If the DEC OSF/1 server responds but an incorrect kernel (vmunix) is 
loaded, it is possible that the server's RIS area is configured incorrectly. You 
can observe the loading process by editing the /etc/inetd . conf file and 
restarting the Internet daemon as described in the previous section, but in this 
case you add the — d option to the line containing the tf tpd command, as 
follows: 

tftp dgram udp wait root /usr/sbin/tf tpd \ 

tftpd -d /tmp /var/adm/ris 

Logging the server's tftp traffic shows you what file is being transferred 
and what time the transfer is started and finished. Observe that the proper 
vmunix file is being loaded and that the loading operations are completed 
correctly. 
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Installing DEC OSF/1 for Alpha AXP * 
Subsets on an ULTRIX Server r\ 



This appendix explains how to install the DEC OSF/1 for Alpha AXP 
software subsets into an ULTRIX RIS server area. 

See Chapter 2 for information about calculating the disk space required to 
install the desired software subsets. 

Note 

You must have the Maintenance Operations Protocol 
subset installed on the RIS server. 

To install the DEC OSF/1 for Alpha AXP subsets into the ULTRIX server's 
RIS area, perform the following steps on the ULTRIX system: 

1 . Log in as root or become superuser. 

2. Create a symbolic link from sh5 to sh by entering the following 
commands: 

# mkdir /sbin 

# In -s /usr/bin/sh5 /sbin/sh 

This link directs DEC OSF/1 clients' accesses of /sbin/sh to the 
correct version of the Bourne shell, which is named /usr/bin/ sh5 on 
ULTRIX systems. 

3. Mount the appropriate media. 

You must either use a CD-ROM device or be able to NFS mount the 
/itint /ALPHA/BASE directory from a DEC OSF/1 system to a local 
mount point in order to extract the DEC OSF/1 subsets. 

If your distribution media is a CD-ROM, enter a command similar to the 
following: 

# mount -r /dev/rz4c /mnt 

This example uses a CD-ROM drive that is unit 4; if your drive is a 
different unit, substitute the correct device special file name for that unit. 

If you are uncertain which device special file corresponds to your CD- 
ROM device, enter the file command, specifying the raw device, as 



follows: 

# file /dev/rrz*c 

/dev/rrzlc: character special (8/1026) SCSI #0 RZ25 disk #8 (SCSI ID #1) 

/dev/rrz2c: character special (8/2050) SCSI #0 RZ25 disk #16 (SCSI ID #2) 

/dev/rrz3c: character special (8/3074) SCSI #0 RZ25 disk #24 (SCSI ID #3) 

/dev/rrz4c: character special (8/4098) SCSI #0 RRD42 disk #32 (SCSI ID #4) 

/dev/rrz9c: character special (8/17410) SCSI #1 RZ57 disk #72 (SCSI ID #1) 

Your CD-ROM device corresponds to an RRD device, in this case 
RRD42. 

If you are mounting the /mnt /ALPHA/BASE file system from a DEC 
OSF/1 server, enter a command similar to the following: 

# mount / mnt / ALPHA/ BASE /mnt 

Replace /mnt with your local mount point, if you are not using /mnt. 

4. Run the /etc/ris command and select the Install Software 
option. 

5. Choose option 1 to establish a new RIS area. 

6. Enter the device special file name or the path of the directory where the 
software is located. 

If your distribution media is CD-ROM, the appropriate device special file 
name is /mnt /ALPHA/BASE. 

If you have NFS-mounted the /mnt /ALPHA/BASE directory from a 
DEC OSF/1 system to a local mount point, enter the name of the local 
mount point. 

7. Choose whether you want to create symbolic links to the software or to 
extract the software into the RIS area. 

8. Select the subsets that you want to make available from this RIS area and 
confirm your choice. 

9. Enter the architecture of clients that your system will serve at the 
following prompt: 

Enter the identifier for the architecture of clients to be 
served from the environment, either mips or vax: 

Because the ULTRIX system does not explicitly support the Alpha AXP 
architecture, you must enter mips in response to this prompt. Do not 
enter alpha. 

The ris utility then displays the absolute path of the new RIS 
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environment: 

The new environment is in /var/adm/ris/risn .mips. 

The n in this display is the next available sequential number in your 
product area. For example, if your server already has a 
/var/adm/ris/risl .mips environment, the new environment is 
/var/adm/ ris/ris2 .mips. 

1 0. Change to the directory of the new RIS environment. 

For example, if the area you just created is ris2 .mips, then enter the 
following command: 

# cd /var/adm/ris/ris2 .mips 

1 1 . Extract the files and create the directory structure required for DEC 
OSF/1 clients by entering the following commands: 

# restore xf */ROOT . /RisFiles 

# RisFiles Extract /var/adm/ris/ris2 ,mips/product_2/ROOT 

Extracting netload ...done, 
netload 

Replace ris2 .mips/product_2 in the preceding command with the 
name of the RIS area you just created and the appropriate product 
number. 

12. Edit the /etc/exports file. 

You must add a line similar to the following for each RIS area that your 
ULTRIX server is serving to DEC OSF/1 clients: 



Your ULTRIX server is now ready to register clients for the DEC OSF/1 for 
Alpha AXP product. 



Before clients use the new RIS area to perform upgrade 
installations, read the Release Notes and the Installation Guide. 
Failure to carefully follow the directions for upgrade installations 
can result in loss or corruption of data. 
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./us-rYvar/adm/ris/ris2 .mips /kit -r=0 -o 



Caution 



Worksheet 



B 



This appendix contains a worksheet for recording setup information for the 
software sharing client. Make as many copies of this worksheet as you need. 



RIS Client Configuration Worksheet 



Network 



System name: 
Hardware Ethernet address: 
TCP/IP network address: 
Internet domain: 



RIS Info 



Client operating system: 
Processor architecture: 
Server system name: 
RIS environment name: 
Products: 



Duplication 



Duplicate another client? NoQJ Yes 
Name of client to copy: 
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Glossary 



This glossary defines terms and concepts related to software sharing, 
client 

A computer system that uses resources provided by another computer, 
called a server. 

product environment 

In RIS, a portion of the RIS area containing a set of software kits that 
are intended for installation on a particular client type, such as RISC 
processors. 

RIS area 

A reserved disk area physically connected to a RISC server, containing 
one or more product environments in which are stored installable 
software kits. 

RIS client 

A computer system that has permission to install software across the 
network by accessing kits stored in the server's RIS area. 

RIS server 

A computer system that serves other computers by providing software 
kits operating system software for them to install; the software is stored 
on disks belonging to the server and is accessed across the network by 
the clients. 

server 

A computer system that serves one or more other computers, called 
clients, by providing a resource to them. 

subset 

An installable software kit module that is compatible with the DEC 
OSF/1 setld software installation utility. 
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A 

architecture 

of RIS, 1-2 to 1-5 



Berkeley Internet Name Domain 

See BIND 
BIND, 4-2 
booting 

RIS client, 5-1 
bootp, 5-1 
bootp protocol 

requirement for, 2-3 
bootpd, 5-1, 5-2 
bootpd daemon, 5- It, 6-3 
bootptab, 5-1 

bootptab file, 5- It, 5-2, 6-2 

c 

CD-ROM 

mounting, 3-1 
client 

adding, 4-1 to 4-4 

for RIS, 4-1 to 4-4 
characteristics of, 1-5 
defined, 1-1 
description of, 1-2 



client (cont.) 

Ethernet address, 4-2 
hardware compatibility, 2-1 
listing, 4-5 
registration, 4-1 

of host name, 4-2 

IP address, 4-2 

naming service, 4-2 
removing, 4-4 
RIS 

characteristics of, 1-5 
troubleshooting, 6-1 to 6-5 
software version compatibility, 2-1 
client registration 

problems, 6-1 
compatibility, server and client, 2-1 
configuring 

procedure for server, 1-2 
creating RIS area, 3-1 

D 

daemon 

bootpd, 5-2 
inetd, 5-1 
internet, 5-1 
tftpd, 5-3 



deleting a client 

See client, removing 
deleting product list, 4-5 
disk space 

planning for RIS, 2-5 
distribution device, 1-1 
distribution media 

See also CD-ROM 

E 

/etc/bootptab file, 6-2 

/etc/hosts file, adding clients to, 4-2 

/etc/inetd.conf file, 6-3 

Ethernet 

See also LAN 
address of client, 4-2 
setting up a client on, 2-3 

F 

file system 

memory-resident in RIS, 1-5 

H 

hardware 

compatibility of, 2-1 
Ethernet address of client, 4-2 
hosts file, adding clients to, 4-2 

I 

inetd, 5-1 

inetd daemon, 5- It 
inetd.conf file, 5- It 
/etc/inetd.conf file, 6-3 
installation 

of network on server, 2-3 



installation (cont.) 

of RIS software subsets 
in existing area, 3-4 
in new area, 3-1 
of server operating system, 2-3 
Internet 

See IP address 
IP address, registering, 4-2 

K 

kit 

See subset 

L 

LAN 

sharing software on, 1-1 
listing products, 4-5 
local area network 

See LAN 

M 

maintenance 

See management 
management of RIS, 4-1 to 4-5 
MOP protocol 

diagnosing failures of, 6-4 

host naming limitations imposed by, 4-2n 

problems, 6—4 

verbose mode, 6-4 

N 

naming service, 4-1 

registering clients, 4-2 
network 

installation of, 2-3 
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network (cont.) 

naming service, 4-1 
Network File system 

See NFS 

Network Information Service, 4-2 

See NIS 
NFS 

using a remote RIS area, 3-4 
NIS, 4-2 

o 

operating system 

installable by RIS, 1-5 
installing on server, 2-3 

P 

planning disk space for RIS, 2-5 
product environment, 1-3 

multiple in single RIS area, 1-4 
products in 

deleting, 4-5 

listing, 4-5 

R 

registering a client, 4-1 

host name, 4-2 

information required for, 4-1 

IP address, 4-2 

with naming service, 4-2 
remote boot 

flow, 5-3 
Remote Installation Services 

See RIS 
removing a client, A-A 



RIS 

adding a client. 4-1 to 4-4 
architecture of, 1-2 to 1-5 
client 

preparing to register, 4-1 
configuration procedure for server, 1-2 
deleting products, 4-5 
disk space 

planning, 2-5 
installing subsets, 3-1 to 3-4 
listing clients, 4-5 
listing products, 4-5 
product environment, 1-3 
remote booting, 5-1, 5-3 
removing a client, 4-4 
server setup, 3-1 to 3-4 
system components, 1-1 
troubleshooting, 6-1 to 6-5 
using an NFS-mounted RIS area, 3-4 
RIS area, 1-2 
contents of, 1-3 
creating, 3-1 

exporting and importing, 1-4 

multiple, 1-4 
RIS client 

booting, 5-1 
RIS daemons 

bootpd, 5- It 

inetd, 5- It 

tftpd, 5- It 
RIS files 

bootptab, 5- It 

inetd.conf, 5- It 
ris.tty.lock file, 6-1 
risdb file, 6-2 



lndex-3 



rislock file, 6-1 

s 

server 

defined, 1-1 
function in RIS, 1-3 
hardware compatibility, 2-1 
management tasks, 4-1 to 4-5 
planning disk space, 2-5 
setup, 3-1 to 3-4 

network installation, 2-3 

operating system installation, 2-3 

prerequisite tasks, 2-3 

RIS, 3-1 to 3-4 
setup preparation, 2- 1 to 2-5 
software version compatibility, 2-1 
setup tasks 

See server, setup 
showing product list, 4-5 
subset 
choosing 

for RIS, 3-3 
defined, 1-4 
descriptions of, 2-3 
installing in RIS 

in existing area, 3-4 

in new area, 3-1 
mandatory, 3-3 
optional, 3-3 
sizes of, 2-3 
subsets, 1-4 



T 

tftp, 5-1 
tftp protocol 

requirement for, 2-3 
tftpd, 5-1 

tftpd daemon, 5- It, 6-5 
troubleshooting RIS, 6-1 to 6-5 

V 

version compatibility, 2-1 

Y 

Yellow Pages service 

See NIS 

YP 

See NIS 
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How to Order Additional Documentation 



Technical Support 

If you need help deciding which documentation best meets your needs, call 800-DIGITAL 
(800-344-4825) before placing your electronic, telephone, or direct mail order. 



Electronic Orders 

To place an order at the Electronic Store, dial 800-234-1998 using a 1200- or 2400-bps 
modem from anywhere in the USA, Canada, or Puerto Rico. If you need assistance using the 
Electronic Store, call 800-DIGITAL (800-344-4825). 



Telephone and Direct Mail Orders 



Your Location 

Continental USA, 
Alaska, or Hawaii 



Puerto Rico 
Canada 



International 



Internal 3 



Call 

800-DIGITAL 

809-754-7575 
800-267-6215 



Contact 

Digital Equipment Corporation 

P.O. Box CS2008 

Nashua, New Hampshire 03061 

Local Digital subsidiary 

Digital Equipment of Canada 

Attn: DECdirect Operations KA02/2 

P.O. Box 13000 

100 Herzberg Road 

Kanata, Ontario, Canada K2K 2A6 

Local Digital subsidiary or 
approved distributor 

SSB Order Processing - NQO/V19 
or 

U. S. Software Supply Business 
Digital Equipment Corporation 
10 Cotton Road 
Nashua, NH 03063-1260 



a For internal orders, you must submit an Internal Software Order Form (EN-0 1740-07). 
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